This section provides background information related to the present disclosure which is not necessarily prior art.
In a communication system, such as an IP bearer network of a Wide Code Division Multiple Access (WCDMA) system, data is transmitted through being carried in a message, such as an IP message. FIG. 1 is a schematic diagram illustrating the structure of a conventional WCDMA network. In the figure, the broken lines indicate signaling paths, and the solid lines indicate message transmission paths for bearing data. The data to be transmitted via an Nb interface between Media Gateways (MGWs) and the data to be transmitted via an Iu interface between a Universal Terrestrial Radio Access Network (UTRAN) and a Media Gate Way (MGW) can be carried by IP messages. User plane parameters can be negotiated by a User Plane (UP) Protocol on the Nb interface and Iu interface. A Mobile Service Control center server (MSC server) controls the MGW by the H.248 protocol via a Mc interface. The above-mentioned network structure may also be used in a fixed softswitch system, a CDMA system, an IP Multimedia Subsystem (IMS) of a fixed network or the like.
For the purpose of bearing data in an IP message, a protocol stack bearing the IP message, as shown in FIG. 2, is constructed. The protocol stack includes a data layer for transmitting data, a Real-Time Transport Protocol (RTP) layer, a User Datagram Protocol (UDP) layer, an IP layer and a link layer. The IP layer may be based on two versions including IP version 4 (IPv4) or IP version 6 (IPv6). The link layer is used for performing a cyclic redundancy check (CRC) on the IP message by an ETHER protocol and a Packet Over SDH/SONET (POS). Detailed descriptions for the RTP layer and the UDP layer are as follows.
The UDP layer is a simple data-oriented transmission protocol layer. On the UDP layer, data transmission channels are reserved respectively for different sessions according to port numbers. A sender sends UDP data via a source port of a data transmission channel, and a receiver receives data via a destination port of the data transmission channel. The UDP layer does not provide reliability, i.e., the sender sends the UDP data, but does not ensure that the UDP data can reach the receiver.
The RTP layer is a protocol layer for providing end-to-end transmission services for data of real time characteristics, such as interactive voice data or image data. The RTP layer is defined to work in one-to-one or one-to-multiple transmission to provide time synchronization and data stream synchronization. The RTP layer usually transmits the data via the UDP layer, and one RTP data packet can be transmitted via two parts, one of which is based on RTP, and the other of which is based on Real-Time Transport Control Protocol (RTCP). The RTP layer is unable to provide a reliable transmission mechanism for the RTP data packets being transmitted in sequence and is unable to provide flow control and congestion control. These services are provided by the RTCP. Sequence numbers in the IP messages may be used by the receiver to reconstruct a sequence of the IP messages sent by the sender and can be used to determine the location of one IP message in the entire sequence of the IP messages sent by the sender. Timestamps in the IP messages may be used to calculate delay and jitter of the network transmission.
FIG. 3 is a schematic diagram illustrating the structure of an RTP header of an IP message. The figure shows the format and contents of the RTP header, and usages of the fields in the RTP header are described as follows. The field of Version (V) is used to indicate version 2. The field of Padding (P) is configured as valid when the IP message has an additional padding byte. The field of eXtension (X) is used to indicate one extended header next to the RTP header (not being used at present). The field of a Contributor count (CC) is used to indicate the number of contributing source identifiers in the IP message with a maximum number of 15. The field of Marker (M), the meaning of which is specified by a session, is used for establishing borders between different data in the IP message. The field of a Payload type (PT) is used to indicate a service type of the data in the IP message. The field of Sequence Number (SN) is used to indicate a 16-bit sequence number of the IP message. The field of a timestamp is used to indicate a 16-bit sampling instant of the first byte of data in the IP message. The field of a Synchronization Source Identifier (SSRC) is used to indicate a synchronous source of the IP message. The field of a Contributing Source (CSRC) list is used to indicate all the contributor sources contained in the payload of the IP message and the number of which is given by the CC.
The data borne in the IP message usually needs to be compressed. When the IP message bearing the compressed data is transmitted via the Iu interface and Nb interface, an UP header needs to be capsulated for the compressed data. FIG. 4 is a schematic diagram illustrating the structure of an IP message bearing the data compressed by an Adaptive Multi Rate (AMR) protocol. The structure is almost the same as that illustrated in FIG. 2 except that an UP layer is added and the data is compressed by the AMR.
UP data messages of the UP layer include control messages and data messages, and the control messages include Initialization messages, rate control messages, time alignment messages and error event messages. There are two types of UP data message: a PDU Type 0 and a PDU Type 1 as shown respectively in FIGS. 5a and 5b. 
In FIGS. 5a and 5b, the UP data message of the UP layer includes a control part, a check part and a payload part. As shown on the check part, CRC checks are performed on both the UP headers of the compressed data and the compressed data if the type of the UP data message is the PDU Type 0, and the CRC checks are performed only on the UP header of the compressed data if the type of the UP data message is the PDU Type 1.
The process for transmitting the IP message bearing data includes two parts: Part I a bandwidth saving capability of the IP message being negotiated; and Part II, the IP message being transmitted. Detailed descriptions of the two parts are given below.
Part I: The bandwidth saving capability of the IP message being negotiated.
Before the IP message is transmitted, one party of a sender and a receiver of the IP message needs to determine the type of the IP message to be transmitted by the other party or the desired type of the IP message supported by the other party, so that a process for negotiating the bandwidth saving capability is needed. Since each bandwidth saving capability corresponds to one type of the IP message, after the bandwidth saving capability is negotiated, the type of the IP message to be transmitted can be determined by the two parties. A conventional process for negotiating the bandwidth saving capability is described as follows. An initiator of the IP message sends a bandwidth saving capability supported by the initiator to a receiver of the IP message; the receiver determines whether the bandwidth saving capability from the initiator is supported by the receiver; if the bandwidth saving capability is supported by the receiver, the receiver sends to the initiator a reply message of a successful negotiation, indicating a successful negotiation; otherwise, the receiver sends a reply message of an unsuccessful negotiation, indicating that the negotiation fails or another negotiation can be initiated.
However, the process for negotiating the bandwidth saving capability of the IP message has following drawbacks, the sender of the IP message only sends one self-supported bandwidth saving capability to the receiver. Therefore, an unsuccessful negotiation or a re-negotiation occurs frequently, leading to a waste of resources in the communication system. For example, two bandwidth saving capabilities of the IP message supported by the sender are indicated as 0 and 1, only the bandwidth saving capability indicated as 0 can be sent to the receiver, while the bandwidth saving capability supported by the receiver is indicated as 1. Therefore, an unsuccessful negotiation or a re-negotiation occurs. Further, in the process for negotiating the bandwidth saving capability of the IP message, there is no definition on how to use the H.248 protocol to negotiate the bandwidth saving capability of the IP message, such as how to negotiate the bandwidth saving capability of the IP message in the case of Non-Tunnel in a circuit-switched core network of a WCDMA system.
Part II: The IP message being transmitted.
When the negotiation for the bandwidth saving capability of the IP message is finished, the type of the IP message used for transmitting data is determined according to the negotiated bandwidth saving capability, so that the data is transmitted via the IP message with the determined type.
At present, there are multiple types of the IP message, and two types commonly used currently are described below.
FIG. 3 shows the structure of a first type of the IP message which includes a compressed IP message header and compressed data, i.e., payload. For the purpose of saving communication system resources taken by the IP message header, the Internet Engineering Task Force (IETF) provides multiple standards of IP message header compression for compressing an IP message header of a session, i.e., compressing an IP header, a UDP header and an RTP header. In the process of the session, a lot of information in the IP message header does not change or changes a little; some information in the IP message header changes, but the difference between the information in two adjacent IP messages is invariable. The above-mentioned two types of information are referred to as stable information. At the beginning of the session, a sender sends to a receiver the IP message which carries the IP message header having the stable information, and then the sender only sends to the receiver the IP message which carries the IP message header having variable information. If the stable information changes in the process of the session, the sender resends to the receiver the IP message which carries the IP message header having the changed stable information. The receiver rearranges the IP message header of each received IP message in the session according to the received stable information and the variable information.
The data transmission by using the IP message with the above-mentioned type of the IP message has the following drawbacks. First, if the IP message which carries the IP message header having the stable information is lost or damaged, the receiver can not correctly update the IP message header of the IP message in the session. Therefore, two parties in the session can not correctly communicate with each other, and thus a mechanism must be provided for detecting whether the receiver has received the IP message header having the stable information, so that the receiver may send a message for requesting the sender to resend the IP message when failing to receive the IP message, but the transmission efficiency of the IP message is affected for it takes time for the messages to be sent and returned in the communication system. Second, the data transmission is suitable for only one session and can not be multiplied by multiple sessions. Third, since the IP message header of the IP message is compressed, the IP message having the compressed IP message header can not pass through routers not supporting the compressed IP message header.
FIG. 6 shows the structure of a second type of the IP message. A multiplex header technique and a RTP compression technique are used for the IP message with the second type of the IP message, i.e., a multiplex header is added to each IP sub-message, and a compression technique is used in the RTP layer. In the multiplex header technique, multiple IP sub-messages in multiple sessions which are identical in the source IP address and destination IP address are multiplied in one IP message, and the link layer, the IP layer and the UDP layer of each IP sub-message are unchanged in formats, and then the multiplied IP message is sent out. In the IP message including multiple IP sub-messages, the destination port number in the UDP header is a fixed value, and the source port number in the UDP header is meaningless. Each IP sub-message includes a multiplex header which indicates the destination UDP port number and message length of the IP sub-message. The RTP compression technique used in the IP sub-message minimizes the RTP layer length by shortening or erasing some fields in the RTP layer. In the RTP layer, the length of some fields can be minimized, such as a timestamp and a sequence number; some fields are unnecessary in some communication system networking environment, such as a P, an M, a CC, an X, a CSRC field and the like are useless in the WCDMA system network and may be removed. The RTP header is compressed after the fields in the RTP header is erased or shortened.
However, the data transmission by using the IP message with the above-mentioned type of the IP message has the following drawbacks.
First, when the multiplex technique is used in the IP message, since no information of the sender is carried in the multiplex header of each IP sub-message, the receiver which receives the IP message can not determine the validity of each IP sub-message in the IP message, and thus reliability and safety concerns may arise. For example, as shown in FIG. 7, firstly, a bidirectional connection is established between Terminal 1 with an IP address of 10.110.100.100 and a port number of 5000 and Terminal 2 with an IP address of 10.110.200.200 and a port number of 6000; and the two Terminals may transmit IP messages to each other. Secondly, after the message transmission is finished, the two Terminals need to be subtracted, and Terminal 1 is successfully subtracted, but Terminal 2 fails to be subtracted for some reasons and becomes a hanging terminal. Thirdly, the IP address and the port number of Terminal 1 is assigned to a subsequent terminal; if the IP address and the port number are assigned to Terminal 3, and a bidirectional connection is established between Terminal 3 and Terminal 4 with an IP address of 10.110.200.200 and a port number of 5000; Terminal 3 and Terminal 4 transmit IP messages to each other. However, the hanging Terminal 2 still sends the IP message to a terminal with the IP address of 10.110.100.100 and the port number of 5000, thus Terminal 3 receives the IP messages from two terminals, and the IP message from 10.110.200.200/5000 is legal, the IP message from 10.110.200.200/6000 is illegal and needs to be discarded. If the IP sub-message of the sent IP message does not include source information, the receiver is unable to determine the validity of the IP sub-message in the IP message; if no determination is made and all the IP sub-messages are taken as legal, the conversation quality will be affected, for example, a crosstalk may occur.
Second, when the multiplex technique is used in each IP sub-message in the IP message, the field for indicating the IP sub-message is so short that the length of the IP sub-message is indicated by at most one byte, and the indicated length is at most 255 bytes. Thus when the IP sub-message is long, the length of the IP sub-message can not be indicated, such as when video data is transmitted or an RTP redundant processing is given to the voice data, the payload length in the IP sub-message may be greater than 255 bytes, and in this way, the multiplex header technique can not be used.
Third, when the UP header is adopted in each IP sub-message of the IP message, no matter which one in the two types of the IP message is adopted, a CRC check needs to be performed on the UP header. However, the CRC check has already been performed on the IP message in the link layer of the IP message, and the correctness of the transmitted data is ensured. Therefore, if the CRC check is still performed on the UP header, the network bandwidth of the communication system is wasted and the requirement for equipment processing capacity is increased.